The emergence of the cloud for computing applications has increased the demand for off-site installations, known as data centers, which store data for remotely connected computer device users. Such data centers typically have massive numbers of racks, plus massive numbers of servers mounted therein to store and manage data. For example, a typical data center may include tens of thousands, or even hundreds of thousands, of devices in hundreds or thousands of individual racks.
Each of the servers in a typical data center stores data and allows access to data from networked devices. Given the plethora of potentially valuable data, there is a need to prevent unscrupulous individuals from stealing the data. FIG. 1 shows a prior art data center system 10 that includes multiple servers 12 in a rack 20. The servers 12 are connected to a network 14 for management of the servers 12. The current security system of such a rack 20 examines firmware integrity of the platform, reviews consistent hardware components of a server motherboard, and verifies authentication of the operating system and user accounts. The current security system requires a login for a device on the network environment to access the server 12.
A secure server is deemed a high security hardware base root of a trusted platform. From the moment power is applied to a server 12, a security process begins to examine firmware integrity of platform; review consistent hardware components of the server motherboard; and verify authentication of the operation system and user accounts and safety network environment. There are two existing secure technologies to support server protection. One involves the Unified Extensible Firmware Interface (UEFI) secure boot, and the other is the Intel® Trusted Execution Technology (TXT) and Trusted Platform Module (TPM). Part of the security process is run from a different entity and can be activity and inactivity by an administrator or a user with the correct authentication. Hence, a secure server could be powered on from the root of trust firmware. The trust firmware may be a hardware base validation of the UEFI power-on self-test (POST) process until booting into a legal operating system with sufficient certification is performed.
In the process of powering a server until it loads the operating system with full software functionality, several and distinct secure examinations must be passed. These secure functions are generic security analyses based on referencing existing security design guides, and automatically inspecting all necessary components. Such necessary components include firmware, hardware, and software of the server platform 12. Once the operating system of the server 12 platform boots properly with all the secure examinations performed successfully, a user with the correct authority can log in to the operating system by using a user name and password. Once proper credentials are presented, the user can activate all software services of the server. The operating system of the server platform may use the Extensible Authentication Protocol (EAP) to authenticate network access for Point-to-Point Protocol (PPP) connections. For IEEE 802.1X-based network access to authenticating Ethernet switches and wireless access points (APs), the EAP is used to establish a trust network connection prior to exchange data through the intranet.
One of potential risk despite these security features is that there is no examination as to whether the network is authentic. Thus, such security features may be circumvented by an individual who covertly obtains an authentic credential such as a user name and password, or if an authorized individual decides to act illegally. In such an instance, an individual may be able to access the actual server if the server is removed from a secured location. Further, there is no method to prevent the server from functioning if a fake user obtains authorization and pretends to be an administrator. Such a process allows unauthorized exposure of the data stored on the server. Further, technical features of the server may be learned under malicious inspection. These scenarios could occur during a server return material authorization (RMA) process, or when the server is stolen by a competitor from the data center.
For example, as shown in FIG. 1, a secure server may not always be located at a safe room or environment with secure protection. A server 16 may be handed over to a vulnerable place when going through Return Material Authorization (RMA) process, or an unscrupulous employee 18 may hand carry the server 16 to a competitor's company. In either of these cases, with sufficient certification, security keys, significant signatures and a username/password that may be stolen, current secure technologies may be circumvented. A competitor may thus easily explore the contents of the server 16, inspect business data, and exercise valuable functions and features of the server 16. In cases of industrial espionage, this may result in speeding up a competitor's development and business via access to valuable data from the stolen server 16.
Thus, there is a need for a system that protects a physical server from being accessed unless it is properly connected to an authentic network. There is another need for a module that prevents a server from being booted up unless proper network credentials are received. There is also a need for a system that secures a credential file to ensure a server is powered up in a safe environment.